I got a copy of the new GS/OS and some strange things are happening.
Some Prodos 8 applications are crashing off the desktop. the only one that works is appleworks. The others work great off the older (3.0)sys disk. I tried replacing the Prodos 8 on the new disk with that of the old and that didn't work either.
The main ones I'm having problems with are ProTerm (terminal program from Checkmate) and Blu 2.28. All my prodos 16 stuff works fine.
Any ideas what I can do to make them work with the new sys disk? Have I neglected to install something from the Tool disk?
If anyone has any experience with this please let me know.
Alan33
Subj: GS/OS and P8 88-10-18 22:59:20 EST
From: AFL Jim
I've been running all of my ProDOS-8 applications after booting GS/OS. I haven't had any crashes yet. That included utilities, AppleWorks, AppleWriter, AppleLink-PE, Mousetalk, Kyan Pascal, BASIC.SYSTEM, etc.
Jim
Subj: Re: GS/OS 88-10-18 23:16:56 EST
From: Dave Lyons
I don't know what would make your P8 applications crash, Alan...if it gives you any readable stuff on the screen, let me know what it is (even if it's a register dump with a bunch of numbers and letters...that's my favorite sort of thing!).
--Dave L
Subj: Re: GS/OS Crashes 88-10-19 20:41:37 EST
From: DennisDoms
Just for reference..I've been running both Proterm (v2.01) and BLU 2.28 with GS/OS since AppleFest, with no problems...
If you have doubts about the "completeness" of your operating system setup (tool set compatibilities, etc.), and you didn't use the Installer to set things up, you may want to go back and use the Installer. It should make sure you have the right combinations installed.
Subj: Re: GS/OS 88-10-19 23:39:45 EST
From: Alan33
DennisDoms,
I did run the stuff I nstalled (5.25 driver was about the only thing and some NDAS from Stylewares DeskWorks including the Menu Clock) with the intaller program. What else should be installed?
Maybe the option "install everything possible"?
Alan33
Subj: Re: GS/OS 88-10-19 23:43:40 EST
From: Alan33
Dennis,
Could I have a bad copy of the GS/OS disk or tool disk?
Everything else seems to work fine.
Alan33
Subj: Re: GS/OS 88-10-20 23:22:08 EST
From: AFA Gary J
Alan,
Certain desk accessories have been known to cause problems from time to time. I'm not saying for SURE that this is your problem, but it is certainly a possibility. Problems with desk accessories seem to pop up when system software is changed. You might try removing ALL your desk accessories from your DESK.ACCS folder, and then try re-booting and run your program. If the program works...then try putting your desk accesories back onto your boot volume, one by one, testing your program after each installation. Using this method you can identify the desk accessory that is causing the problem, and remove it. Let us know if you discover the problem.
Gary
Subj: Re: GS/OS 88-10-21 08:13:23 EST
From: AFL Floyd
Styleware's Menu.clock is probably one of the problems. It is known to cause crashing on a lot of programs. I'd ditch that one for sure.
Floyd
Subj: Re: GS/OS & P8 88-10-21 21:13:25 EST
From: TMH2
Why does P8 still exist on a GS/OS system?? Why don't we have a 'P8 emulator' which creates P8-style tables & MLI entry, but calls code which calls GS/OS?! Worst of all, I can't write one, because GS/OS now vectors to old P8-only space in bank 0. What's the deal?!?
T. Mike Howeth
Subj: Re: GS/OS 88-10-22 22:51:02 EST
From: Alan33
Gary,
I thought the NDA thing was the problem.
It wasn't. My stupidity was.
I went back and looked at the installer program again. There was this neat line that said "install system files". I did that and low and behold all my prodos 8 programs now run.
I don't know how I missed that one. Although since the file names were in the system folder I figured the stuff should work. I was mistaken.
Oh well, live and learn (and spend lots of money)
Thanks for everyones help.
Alan33
Subj: Re: GS/OS 88-10-30 17:49:53 EST
From: WalterP12
I am having a problem with GS/OS, 5.25 and ramdisk (RamFactor). The operating system will recognize all three, but if I have the driver for the 5.25 disk in I don't know how to get the ramfactor to show up. It does so only when the driver for the 5.25 is out.
Am I doing something, not doing something or is it the operating sytem ?
Thanks for the help.
Subj: Re: GS/OS cache & ramdisk size 88-11-20 03:22:52 EST
From: AndyBoy1
SamT2:
I just finished leaving a somewhat lengthy message under "GS/OS Bugs" - the folder - describing the operation of the GS/OS cache. Making a long story short, 512k cache is -way- too much. For the most part the system only caches directory & bitmap blocks anyhow, so it's probably never all used. And you pay a penalty in large caches, not only in memory use but in the time spent searching through them.
Andy Stadler
Apple II System Software
Subj: Re: GS/OS cache size 88-11-20 12:32:41 EST
From: Founder
Andy thats interesting (512k cache too large). What would be the optimum cache size then? I suppose something on the order of 64k or less would be all that is needed for caching dir blocks.
Mark
Subj: Re: GS/OS 88-11-21 21:42:19 EST
From: AFA Parik
You must have one big directory if it takes 128 blocks...:-)
So thats why in Orca shell, if I delete a file off the HD on the other CMS, it won't register on this GS... any way to FORCE it to read the directory from the disk itself, instead of cached ram?
Subj: GS/OS and caching shared devs 88-11-22 03:10:30 EST
From: Dave Lyons
Ouch! Caching anything at the block level from a shared device is _very_ dangerous to the integrity of your volume. You are badly in need of a GS/OS device driver for your drive that _never_ caches any blocks. Even without caching, your volume is still in danger if you have no way to prevent two machines from fiddling with a particular file or directory at the same time, not to mention the bitmap blocks. Don't even want to _think_ about that....
Subj: Re: GS/OS 88-11-22 21:37:15 EST
From: AFA Parik
Living on the wild side...:)
Actually I've been pretty safe so far, one will be in ProDOS 8 while the other is in GS applications. Works out well.
Subj: shared devices 88-11-22 21:39:41 EST
From: Dave Lyons
As Arthur Dent said in Episode 1 of _The Hitchhiker's Guide to the Galaxy_ (by Douglas Adams),
"Ah. This is obviously some strange usage of the word 'safe' that I wasn't previously aware of."
<grin>
What happens if you create a file with the machine running P8 and then create a file with the machine running GS/OS? Doesn't GS/OS have a cached image of the volume's bitmap block(s), and therefore an outdated idea of what blocks are free?
This is not the only problem I can imagine, but it's the one most likely to trash your disk completely in the shortest amount of time. :-) [For other amusing ways to fry disks, try shifting all the bytes in block 6 forward one & inserting a $55 at the beginning! This has happened to me, unfortunately.]
I'd run MR.FIXIT on that volume _very_ frequently...
Subj: Re: GS/OS 88-11-23 01:23:29 EST
From: JSchober
This has nothing to do with GS/OS, but speaking of that thing on block 6... back when I was still using the <shuddddder> Rev. A SCSI ROM on the GS, the system had this disconcerting habit of taking an index block -- of a LARGE, IMPORTANT file, such as the PASSWORDS/user accounts file on my BBS <small, unchanging files aren't any fun to trash, now, are they??? ;) > -- and replicating the first 256 bytes on the second 256 bytes. That is, it would take all the low bytes of block numbers and copy 'em onto where the high bytes of the block numbers were.
Loads of fun. Searching every 256th block on a 40,000 block disk isn't much better than searching EVERY block on that disk. Took 7 hours of dedicated block editing to fix. And it happened TWICE.
'Twas definitely a good incentive to get the SCSI upgrade.
<sigh>
Subj: Re: cache size 88-11-23 02:55:06 EST
From: AndyBoy1
Cache size:
This is purely opinions. I tend to run mine pretty small, 32k or 64k. However, when more true GS/OS apps start to appear (like the one I'm writing :-) ) and they use class 1 read calls with intelligent caching control ( like the one I'm writing :-) ) the optimum cache size is going to go up. A bit.
Multi-drive systems:
As has been so eloquently described, caching on multi-cpu peripherals is DANGEROUS. In a word, -don't-.
--Andy
Subj: disabling GS/OS caching 88-11-26 23:11:54 EST
From: Dave Lyons
I think you'll have to write your own loaded device driver if you want to avoid caching. That will solve _part_ of the problem--you still have to avoid doing certain sorts of things, like doing _anything_ that allocates blocks on the volume using one machine while any files are open & may be written to on the other machine. And you'd want to avoid simultaneous operations that make any kind of change to a directory, unless you're sure it's different directories & neither directory will grow [which would cause the bitmap to be fiddled with].
There is no concurrency control built into the ProDOS volume structure (I mean, no way to mark a directory block or a bitmap block as "WAIT! I have a copy of this in RAM and will rewrite it shortly"), so you still need lots of intestinal fortitude to share a device.
I don't know whether P8 or the ProDOS FST does any caching with no files open other than through the device drivers. If it does, you could still be out of luck with those bitmap blocks, for example
Subj: directory caching (Floyd) 88-11-26 23:19:00 EST
From: Dave Lyons
Forwarded message (from the wrong folder :-)
----
Subj: Disable directory cacheing 88-11-24 10:17:26 est
From: AFL Floyd
I don't think it is possible to disable the directory cacheing feature. If you don't want to use the benefits of GS/OS, you might want to go back to using P16. :)
Floyd
Subj: Re: GS/OS 88-11-27 20:28:30 EST
From: AFA Parik
Heheh, Floyd was obviously enjoying his holiday so much he staggered through the folders. :)
For those with the same problem, what I do is reboot upon a write by a different computer. Obviously I am rebooting FREQUENTLY. I do have Orca on ROM disk so its not very bad. Every time you are writing to the disk with a different computer, you need to reboot. *sigh* Also NEVER, EVER, EVER read & write at the same time with a CMS, you can read/read at the same time, but thats the extent of it. Even on different volumes [ie, the second partition]. What I'm going to do is create a image of my first hard drive on the second hard drive, so I'll have two systems that are different but are identical. Gotta find time to copy 40 megs now...*Grin
Subj: GS/OS Pathname Storage 88-12-29 01:29:19 EST
From: AFA Parik
Does GS/OS *really* change Storage Types 1-3 to 1? I mean the storage types as in SPARSE,TREE,etc -> STANDARD, EXTENDED,DIRECTORY/SUBDIRECTORY as per the GS/OS documentation. Well, I keep getting storage type #2 instead of type #1 when I'm editing a file, I do play around with the storage type however and before I go in and find out what is going wrong I want to make sure GS/OS does indeed change all storage types that are NOT $05 and $0D into $01.
Subj: Re: GS/OS 88-12-29 20:29:42 EST
From: TMH2
It does on a create.
Subj: storage type in Create parmlist 88-12-30 00:21:54 EST
From: Dave Lyons
Yes, the storage type parameter is changed to a 1 after a CREATE call if it was a 2 or 3. 5 (extended) and $D (subdirectory) are left alone.
Subj: Re: GS/OS 88-12-30 21:34:52 EST
From: AFA Parik
Heh, thanks, I thought I imagined the docs said the OPEN call returned with the values as standard/extended/dir ONLY (since those were only listed :), a few minutes of fiddling settled that question. :-)
Subj: Re: File Storage Types 89-01-27 03:55:06 EST
From: AndyBoy1
Regarding 1, 2, and 3 changing to 1:
At the application level, GS/OS only supports 3 storage classes:
1 = data only file
5 = data + resource file
D = subdirectory
That's it. For P16 compatibility, storage types 2 and 3 are mapped to 1.
I have just described the application level interface to GS/OS. Now, the Pro.FST implements a file system which we all know and love, which has a 32 MB limitation, etc, etc. And supports type 2 and 3 storage classes. But "gs/os" applications only know file/resource/subdir, so those values on a ProDOS disk are mapped back to 1.
Remember: The Application Level interface is not necessarily the ProDOS disk structure.
--Andy Stadler
Apple II System Software
Subj: Re: GS/OS Bugs 88-10-22 20:20:54 EST
From: Matt DTS
Pardon my bluntness, but I don't believe any of it. We tested most of what you say and had no problems. Please be more specific:
1) "GS/OS wrote to the wrong file." Are you sure the program didn't use the wrong reference number, or "assume" some device name when it shouldn't have?
2) Tools are locked down while executing and therefore can not be compacted. If what you're saying is that the Window Manager has an unlocked handle that it doesn't re-dereference after compaction occurs, then that's a different story. Please give more details and we'll try to track it down.
3) The disk cache and /RAM5 both use memory obtained by the memory manager, and there is no conflict. What do you mean by "don't get along"?
4) Same thing with the APW Linker. However, if you have your cache set too large, the linker could possibly run out of memory. Again, what do you mean by "don't get along"?
(I'll address the other one in the next memo since I have to go back and look to see what it is again.)
--Matt
Subj: Re: GSOS Bugs 88-10-23 13:22:44 EST
From: HErwin
GSOS wrote to the wrong file--just so. The application had about 20 files open at the time (it's a full-fledged RDBMS) and it was using C file i/o calls. The block ended up in one of the index files, not in the underlying data file. Simultaneously the event queue went blooey. I had to do quite a bit of work to recover.
Cache and /RAM5 don't get along--In the finder I was having trouble copying files into /RAM5. The cache was set to 64 blocks. I would consistently get a blowup in /RAM5 after transferring about 63 blocks. Memory is OK. Similar blowups were occurring when I ran the linker.
Window manager problems--I have a game under development that redraws a window frequently. Eventually, the redraw got garbled. I also have the TML calculator and clock as NDAs. I brought them up and left in the corners of the screen while running Hodge Podge. I went through a number of windows, and eventually when the screen was being restored after closing a window, the face of the TML calculator became garbaged.
Signed, "Black Thumb" Harry Erwin, an experienced beta tester.
Subj: Re: GSOS Bugs 88-10-23 17:13:02 EST
From: AFA Parik
Harry, have you tried some of the problems under the old
system disk? Obviously not the 20 open-file problem (heh, I
would imagine you'd have INSTANT problem there ;), but the
window manager stuff? In the orca/desktop I'll have multiple
windows open at once without a problem.
What does it do to the /RAM5 volume? Garbage up the entire
disk, or just stop copying things?
Subj: Re: GSOS Bugs? 88-10-23 17:47:42 EST
From: Dave Lyons
>GSOS wrote to the wrong file--just so. The application had
>about 20 files open at the time (it's a full-fledged RDBMS)
>and it was using C file i/o calls.
There isn't enough info to determine whether it's a GS/OS problem, a ProDOS FST problem, an APW C library problem, a bug in your C program, or a bug in *any* other part of the system. Anything that stomped on memory not belonging to it *could* cause damage to GS/OS code or data structures, with the end result that you experienced.
Whereever the problem is, I want to help you find it. If it *is* a GS/OS problem we need to find a way to duplicate it so we can present it to Apple.
>Cache and /RAM5 don't get along--In the finder I was having
>trouble copying files into /RAM5. The cache was set to 64
>blocks. I would consistently get a blowup in /RAM5 after
>transferring about 63 blocks. Memory is OK. Similar blowups
>were occurring when I ran the linker.
I've never had trouble with the Cache and /RAM5 myself. What sort of trouble were you having copying to /RAM5? If the minimum and maximum on /RAM5 are not equal, the Finder will be unable to copy large amounts of stuff to it at one time. This is because /RAM5 requests memory as it is written to when max>min, and the Finder may already be using all the available memory for the stuff it just read and is trying to write.
What is a "blowup"?
Window manager/hodge podge/TML Calculator problems--again, there isn't enough info to narrow down the problem. There may be a problem with Window Manager, Hodge Podge, the TML Calculator, or *any* other part of the system. The first step is to be able to to duplicate the problem reliably if possible. Utilities like Nifty List can be very useful in helping track down problems. (Nifty List is Shareware, available in the library, by me.)
--Dave Lyons
Subj: /RAM5 clarification 88-10-24 01:10:39 EST
From: Dave Lyons
To clarify, /RAM5 starts out allocated to its MINIMUM size setting, and it grows up to its maximum as necessary. If you set min=max, /RAM5 won't have to allocate memory on the fly.
Subj: GSOS Bugs or Bad RAM? 88-10-24 16:10:32 EST
From: AFL Jim
I might ask how you *know* you've got good RAM?
Apple's built-in (closed-apple/control/reset) won't find anything but completely dead RAM - either will Apple Dealer Diagnostics. They both read too quickly after writing to catch chips that don't like the CAS before RAS refresh method. I could use a better test if anyone has one :)
Jim
Subj: Re: GSOS Bugs 88-10-24 17:35:41 EST
From: HErwin
I had a work-around for the 20-file problem (actually 35--I counted)--close when not in use.
Window manager problem is new. It's OK on 3.1.
RAM5 condition is trashed. The OS tells me so when I try to mess with it.
Looks like I've got a new one. With 35 files open, lseek (C) gets lost. Location is 5880 (base 16) into the file. Whence is 0. File is #13 (base 10). Record before can be found easily. lseek had just found the record, and I was about to do a random write. Interesting. Further reports later this week.
Harry
Subj: Re: GSOS Bugs 88-10-24 17:42:33 EST
From: ScottG25
Jim,
I mentioned almost the same thing to Harry on StarPort (he's a regular user there), and outlined how to write an efficient memory diagnostic. To make a long story short, ram was my problem with GS/OS as well _AND_ the diags (from disk) did not catch it, either.
Scott
Subj: Re: GSOS Bugs 88-10-24 17:44:41 EST
From: HErwin
I'll put together fuller problem descriptions over the next few days. The Hodge Podge problem is easiest to recreate. Recompile it in C, change it to S16, and launch it. Do some up and downs with font windows with the TML calculator and clock underneath. I'll spend some time putting together a procedure this week. . . .
Harry Erwin
Subj: Re: GSOS Bugs 88-10-24 17:47:28 EST
From: HErwin
RAM is 1.28 Meg. Settings were 256/256. Nothing on RAM5 at the time. Cache was 64K.
Harry
Subj: Re: GSOS Bugs 88-10-24 17:49:36 EST
From: HErwin
Possible problem. I used the dealer diagnostics to check. The chip numbers are supposedly good.
Harry
Subj: Re: GSOS Bugs and RAM 88-10-24 22:14:57 EST
From: AFA Gary J
Is it just me, or is GS/OS more sensitive to RAM timing than previous operating system versions? (And if so, why??) I had to replace some of the chips on my RAM card when I got GS/OS because it wouldn't even boot properly with the RAM I had (it kept giving weird file errors, like end of file error, and stuff like that). Before I got GS/OS, I had NO problems with my memory (at least that I noticed). Things have been running smoothly since I changed the chips. (Anyone else have these problems?)
The memory test I use for testing my chips is the Checkmate MultiRAM GS software. In order to obtain reasonably accurate results, you must run any IIGS memory test for two hours or more (overnight, if possible).
Gary
Subj: Re: GSOS Bugs 88-10-24 22:49:41 EST
From: ScottG25
Gary,
Yes! I had a problem that I posted to earlier in the large GS/OS folder. It concerned an _Open call (P16 type) resting on a page boundary. The program the call was in always got loaded at the same place (my system configuration didn't change at any time). It turns out that I had some bad ram that the GS dealer diags, didn't catch. The way I found it was to write a small program that just kept reading - comparing - and writing the call sequence back into ram at that page boundary. After about 5 mins the small program bombed with the A-reg not what it should be (the compare was done with immediate values isolated from the bank in question after loading the A-reg with the suspect addresses value--of course this assumes the A-reg is not bad). Maybe the problems are surfacing because of the speed increase in GS/OS (timing as you mentioned). I've seen quite a few of these type problems surface on other computers (DEC-VAX) after a major OS release (rare, but the do occur). Perhaps Matt knows others who have had similar experiences with Apples.
Subj: Re: GSOS Bugs 88-10-26 19:38:09 EST
From: DennisDoms
I don't know of any of the "generic" RAM tests that will catch the (non) CAS-before-RAS problems. I do know that my IIgs passed all the Apple diags repeatedly (we're talking >12 hour run times here) and never reported a problem with the memory, which ultimately *was* the problem (confirmed with the chip manufacturer, thanks to Checkmate Technology). Moral: don't trust the diags. My experience is that programs are much better (unfortunately) at finding problems (ain't they always?). :)
AFL Jim called me today and was hot on the trail of a proper RAM test method. I can tell you what I used to demonstrate a problem on the IIgs: create a RAM5 volume the size of your RAM card, fill it with files, and start verifying the files S L O W L Y (that is, pause several minutes). I noticed that I couldn't re-boot off the RAM disk if I left it (and the computer) "idling" with 8-bit software (ProDOS 8 or Apple Pascal OS) for about 15-20 minutes. Apparently the key is to have a sufficient time lag between accessing the address lines of the memory card chips so that you can see if the internal refresh circuitry is working (Jim is tracking down a suitable way to implement this in a test).
Subj: Re: GSOS Bugs 88-10-26 20:42:16 EST
From: SkipS
I can verify from personal experience that the Dealer Diagnostic
doesn't catch many RAM problems. RAM failures can obviously cause all kinds of strange results, which is what I was having after upgrading to GS/OS. The diagnostics reported no errors, yet I just knew there was something fishy. I decided to inspect the RAM chips and reseat them anyway and low and behold I found a bent pin that was very well desguised. I haven't had a problem since and I can't explain why the failures began after I upgraded. I never opened the machine so I know it was like that before the upgrade. Moral: check and double check your RAM chips for bent pins and proper seating! The diagnostics are not fool proof!
Skip
Subj: Re: GSOS Bugs 88-10-26 20:43:37 EST
From: ScottG25
That's quite interesting, I wonder, did it do it every time, Dennis? This almost implies that it is a memory synchronization problem (interaction of MegaII and FPI chips)... Interesting... Please post more information, when you get it! I hope Jim comes up with something good... I wonder just how the diags tests, and if they test for crosstalk by writing to one address, and then reading the addresses to either side of the one being written to and checking for a change... Interesting stuff!
Subj: Re: GSOS Bugs 88-10-27 11:45:45 EST
From: AFL Jim
Maybe we should start a new topic on memory test routines??
Subj: Re: GSOS Bugs 88-11-03 18:20:46 EST
From: Chip65816
I have had problems which I think I have traced to the Cache DA.
I am using a Battery-backed RAM disk in slot 6 with 1MEG. I did not have any problems until GS/OS. After Installing the system files, everything seems to work fine, but after a few hours of file manipulation etc., I get Bad Blocks out of range according to Mr. Fixit. Data is missing in the RAM volume. If I don't do anything, eventually enough files get messed up that GS/OS won't boot (it crashes into the monitor on load or other bad things). If, however, I set the Cache to 0K, I have no problems at all. (At least not yet) Any ideas?
Chip Welch
Subj: Re: GSOS Bugs 88-11-04 15:34:22 EST
From: AFL Jim
Chip, this could be another in the series of bad DRAM problems.
Subj: Re: GSOS Bugs 88-11-05 16:43:00 EST
From: AFA John
Jim,
You mentioned bad RAM in the previous message and I was wondering whether this is becoming prevalent now days. This is not the first time I have heard mention of bad RAM and would like to know what is causing it, or who's chip are the problems.
John
Subj: Re: GSOS Bugs 88-11-05 21:53:40 EST
From: JimLaz
The easiest solution is to keep your Catche set at 0K. Apparently GS/OS is thinking the RAM/ROM Disk is a 800k drive and is acting strangly. I have RAMKeeper and the Catche works fine with it.
JimLaz
Subj: Re: GSOS Bugs 88-11-06 03:19:45 EST
From: Dave Lyons
Mmm...I dunno about that--if you've got bad RAM, setting your GS/OS cache to 0 is only a temporary solution at best. & I'm confident that GS/OS does *not* think your disk cache is a disk device. I use a variable-sized 0-1024K /RAM5 with a nonzero GS/OS cache with no apparent problems.
--Dave L
Subj: Re: GSOS Bugs 88-11-06 21:27:07 EST
From: JSchober
Excuse me for being ignorant (again), but does the GS/OS Cache cache ONLY directory blocks, or also data blocks?
Anyway, what's the verdict .... is the Cache too dangerous to be worth using? :( You people seem to use GS/OS much more than I do.........
--Joe
Subj: GS/OS cache 88-11-06 23:05:03 EST
From: Dave Lyons
Joe, *if* you trust my memory:
GS/OS *always* has a 16K cache for directory blocks. In addition to that, you can use the Cache NDA to set a nonzero size for your data block cache; data blocks are cached *only* during class-1 GS/OS calls that specifically request it (so stuff that was written before GS/OS came out will never cache data blocks).
Subj: Re: GSOS Bugs 88-11-09 22:46:42 EST
From: JSchober
Alright, I'll buy that...
And that's where the SESSION feature comes in??
<no, I STILL haven't gotten the GS/OS Ref. It costs more than $2.32. :( >
Subj: Re: GSOS Bugs 88-11-10 02:19:13 EST
From: Matt DTS
Joe:
Don't be cheap. We worked hard to make it a good book. :-)
GS/OS automatically caches "system" blocks (directories, bit-maps, etc.) and will cache "application" blocks (non-system blocks) on request. See GS/OS TN #3, "Pointers on Caching", arriving upon your steps sometime this month, certified developers.
--Matt
Subj: Re: GSOS Cache 88-11-20 02:57:01 EST
From: AndyBoy1
Matt already answered part of this, but I'll throw in my $0.02.
CACHE SIZE
The GS/OS cache is a variable-sized cache, adjustable by the user from 0-n where n depends on the total system RAM size. However, turning off the cache would hurt the system so much that it actually bottoms out at 16k.
ONLY ONE CACHE
There is only one cache. Caching is -handled- by device drivers but is -controlled- by FST's with some guidance from the applications. What the heck does that mean?
First, although a driver receives a "cache-request" flag as part of a read or write call, it is up to the driver whether to cache or not. This is because some devices should not ever be cached, and only the driver knows for sure. For example, a RAM disk driver knows that RAM disks should never be cached.
The FST's make the cache requests because the FST's can make better cache decisions on a block-by-block basis. There is no such animal as a "directory" cache or a "data" cache. The ProDOS FST (-not- GS/OS) makes the following cache priority decision: "system blocks" are cached, and "data blocks" aren't.
APPLICATION CONTROL OF CACHING
An application using Class 1 calls may override the cache priority and request caching of data blocks. Matt mentions a technote which describes this aspect better, but to summarize, don't cache entire files. Only cache segments of files which are repeatedly used.
SESSIONS
The GS/OS cache is a 'write-through' cache. This means that while a read call may simply copy from the cache, every write call generates disk activity whether cached or not. This is a safer cache because the disk itself is always up-to-date.
Sometimes, however, an application may be able to 'group' disk activities. These should be sequences of disk activities which will always occur together, with no opportunity for the user to remove the media. For example, if I made an entry in my home accounting package and it had to go out and update the ledger, payroll, finance, taxes, and misc files all together, this would be a place to use a session.
When you turn on sessions, the cache becomes write-deferred. If you write to a block in the cache, it will simply update the data in the cache. If the cache is full and a dirty block must be purged, it will first be written to disk. The application must now make a complete sequence of disk activities.
Finally, when the session is ended, the entire cache is scanned and all dirty blocks are written to the disk. BUT: They are written in block order, so the head won't thrash; and blocks which were updated more than once during the session, are still only written once.
Hope that clears up some of the confusion.
Andy Stadler
Apple II System Software
Subj: Re: GSOS Bugs 88-11-23 01:18:39 EST
From: JSchober
Dave... I agree totally! I usually don't stay in GS/OS long enough to have gotten any directory blocks majorly scrambled (only one bad-file-count error), but I'm not particularly looking forward to that day, either. Checksums are easy to do, and practically foolproof. (Yeah, yeah, you could do CRC's or triplicates of every block for verification purposes, but all you NEED is something simple like a checksum!) If we get lucky, maybe we'll see that added in System 4.1. :)
Matt... Well, $2.32 is an approximate figure, yes, but it's roughly accurate. It'll be a while before I can afford any books, <sigh>.
And we won't even think about where my certified developership went to, so I'll just wait for the TN's to hit ALink.
Bloop.
--Joey
Subj: Re: GSOS Bugs 88-11-25 21:38:25 EST
From: Guy Rice
I have my GS/OS cache set to 256K (I have 2.25megs of total RAM, so I can afford to set that much aside), and I've never had any problem with it either interfering with /RAM5 (set to 128K on my system) or with it having its contents scrambled with random stuff like Dave's font-list-in-the-directory problem. However, I'd feel safer knowing there was a checksum of some sort - I've accidently trashed memory before while programming in assembly. (I really hosed over APW once... well, more than once, actually... :) If you think it would take too much time, maybe you could make a "checksum cache" bit in the system preferences or something that could be left normal by all programs except assemblers, compilers, and stuff like that...
GTR
Subj: Re: GSOS Bugs and Disk cache 88-12-24 12:46:03 EST
From: KKASHMAREK
I have found the discussion about cache all very interesting. Micol Advanced Basic loads up my cache, set at 512K, and seems to lock in about 160K, and no application is able to use cache again after that. For example, using ORCA/Pascal, first CMPL command for a source file loads up the compiler and linker in memory. Second CMPL is much faster since these modules are memory restartable. Also, second CMPL does not access hard disk for link library searching. After running Micol Advanced Basic, this is no longer true. Compiler and linker must be reloaded from disk, and second CMPL does not take advantage of cache for link library searches (much disk I/O during linking).
Sure wish the default for cache use was yes by the ProDOS FST. Could make everything faster, and force use of the cache LRU algorithm to see if it really works. Certainly glad directory blocks are cached and bit maps. The bit map is critical for large volume hard disks that are almost full. I don't use RAM5 since I have a slot based RAM card available. I keep the cache set to 128K normally, although it seldom gets above 32K.
Subj: GS/OS Bugs 89-01-24 19:37:22 EST
From: BrianG19 Msgs: 35 (89-02-07)
I have found several bugs in GS/OS, bugs which have been verified with other developers:
1] When saving large files consisting of mostly $00's, the file size in the directory are very,very wrong. EX. Create a black picture with a paintprogram (all $00) and save it. Some programs will not load it back in, because the filesize is wrong. Or, if you go to the finder and try to copy a previously created file of the same genre, the new copy will have the wrong file size also.
2] It seems that on occasions, the loader will write a few bytes into the program, thus crashing it occasionally, or the relocator does not work.
I am interested in what other bugs have been found.
-Brian Greensto
Subj: Re: GS/OS Bugs 89-01-24 20:43:02 EST
From: DennisDoms
Item 1 ("small" files) is probably due to the ProDOS FST making files with long runs of $00 bytes sparse; check the endfile for the file size (not the block count). If the application is not identifying the file correctly because it's checking the block count rather than endfile, then it's the application's fault.
Subj: Re: GS/OS Bugs 89-01-25 14:05:05 EST
From: AFL Floyd
Dennis is quite right. Certain paint programs, like PaintWorks, look at the block count instead of the EOF size like they're supposed to. Lousy programming.
The ProDOS FST *automatically* creates sparse files when writing out zeroed blocks. This would be invisible to any application that was written properly.
Floy
Subj: Random Bytes? 89-01-25 22:41:08 EST
From: AFA Gary J
Brian,
What do you mean by random bytes being written into the code? Could you be more specific?
Gary
Subj: Re: GS/OS Bugs 89-01-25 23:27:39 EST
From: DaviesDoug
Yah, I noticed the sparse file creation too. I was doing a SHR screen save (desk accessory) and my file kept coming out to 43 blocks instead of 65. Man was I confused. But I did a CMP in ORCA and sure enough the files are the same. Pretty neat! I am working on an application that copies files and was worried I would have to treat sparse files differently, but GSOS is going to do this for me automatically! DEFINATELY NOT A BUG, it is a wonderful feature, just confusing at first.
I've gone through and recopied alot of my files to make them smaller. Alink.Sys16 gets cut down by like 100 blocks if you copy it under GSOS, and loads a little bit quicker!!!
Subj: Re: Random Bytes 89-01-28 12:40:58 EST
From: BrianG19
What I mean... and I have heard of the same thing happening to other developers... is that my application which I am writing will crash 100% when I used GS/OS, not Prodos 1.6. Its not the program's fault, because if I link the files in a different order, then it crashes in a different part of the program, and when I was trying to find the bug, I eliminated it down to the first 50 lines of my program which is just tool startup calls which are perfectly valid unless there has been a change in the tool call protocol with GS/OS. Other people have reported the same thing, but its impossible to trace the bug anyfarther back than to the ToolStartUp calls. I dunno...
-Brian
Subj: random memory trashing 89-01-28 16:14:06 EST
From: Dave Lyons
Brian, I seriously want to get to the bottom of any random memory trashing which may be going on anywhere in the system. It _is_ possible to trace this kind of thing--it may not be fun, but it is possible.
If you are willing to e-mail me part or all of your program via "Send File By Mail..." in the post office (either source or object), I will see what I can figure out. There are a _lot_ of things you can do wrong in tool startups, etc, that will not always cause problems, or at least not noticable problems.
It's also certainly possible you're being bitten by a legitimate bug in the system, but either way, I want to get to the bottom of it: either to restore your confidence in the system or to get the bug repaired.
--Dave Lyons
Subj: Re: GS/OS Bugs 89-01-29 20:44:19 EST
From: AFA Parik
The only thing I can think of is the #$012000 reservations... it could be crashing there since $012000+ will PROBABLY be used when running (especially if you are in Orca/M, etc). Try running the program through the debugger and seeing where it crashes exactly...
Subj: Re: GS/OS Bugs 89-01-30 20:20:56 EST
From: BrianG19
I am using Merlin 8/16, but I dont think thats the problem, because EVERYTHING works PERFECTLY under P16... Its GOT to be GS/OS.
Subj: Finding the bugs 89-01-30 22:12:18 EST
From: Dave Lyons
Brian, the reasoning "It works with P16; it doesn't work with GS/OS; GS/OS is buggy" is wrong. In the GS environment there are a lot of things your program can do wrong that will _eventaully_ cause you a problem, when you get unlucky enough to have the memory you trash be important.
In the case of the code you posted a few messages back, the problem is that your code assumes the B register is set to some particular bank, when in fact it has a no defined value at that point. (I'm assuming that the code you showed is everything that has executed starting with the beginning of your program.) All your loads and stores of MyID, MasterID, XHandle, CharSetHandle, etc, are happening in a _random_ 64K bank of memory, usually one your program doesn't own. As "luck" would have it, it seems that when you run your program under GS/OS with your particular set of DAs & drivers installed, your "global variables" bank is in a different bank from your program code, and the B register happens to be set to your program code bank! So your own STAs are trashing your code. [At least, that's how it appears to me w/ limited info about your program--I don't know how many segments it has, for example. You might take a look at Nifty List in the library {Shareware, $15, by me}, since it will easily show you what memory your program owns, among many other things.]
If your globals are in the same segment as your code, you can use PHK PLB to set the B register. If they are in a different segment, use something like
LDA #MyID|-16
XBA
PHA
PLB
PLB
Let me know if this solves your problems!
--Dav
Subj: non-GS/OS bugs 89-01-30 22:22:26 EST
From: Dave Lyons
Forgot to mention 2 other things in your code, Brian: you should check for an error code after the NewHandle that tries to allocate the $600 bytes of direct page space; and be careful about using the CharSet value, because your code leaves the handle unlocked. CharSet will become invalid on the next operation that can allocate memory [which is not the same as saying it will fail in an obvious way...using the pointer anyway might not cause a crash for a long time...like until you release your program!].
--Dave
Subj: Dave do you really waste 2 bytes 89-01-30 23:12:04 EST
From: DaviesDoug
Dave:
PEA MyId|-16
PLB
PLB
works a lot better than the way you did it (saves 2 bytes)
Subj: Re: Wasting 2 bytes 89-01-31 00:07:57 EST
From: DaviesDoug
Ooooops goofed:
PEA MyID|-8 ; not |-16 sorry
PLB
PLB
:)
Subj: Re: GS/OS Bugs 89-01-31 19:17:47 EST
From: BrianG19
Dave,
The data bank stuff is NOT the problem. The 2 lines before the routine I listed is called the following lines are executed:
phk
plb
so, that's not why it crashes... I dunno.. my instinct says GS/OS.
-Brian
Subj: wasting 2 bytes 89-01-31 20:22:17 EST
From: Dave Lyons
Doug, no--typically I don't waste two bytes. Instead, I write in Pascal or C and waste a whole bunch of them.
Subj: finding the bugs 89-01-31 20:24:46 EST
From: Dave Lyons
Brian--Okay, fine. Let's start again, then. Before you blame GS/OS, you're going to have to show us all the code your program executes up until the point that something has definitely been trashed. Don't leave anything out. If it's too large to post the source, then use "send file by mail" in the Post Office to send me either the source or the object, as your prefer, and I'll take a look at it.
Your code may or may not be at fault; if it is, I'll find the problem, and if it isn't, then I'll be well on the way to finding a bug in the system somewhere.
Subj: Re: GS/OS Bugs 89-01-31 21:56:05 EST
From: AFA Parik
Brian,
running the program under the APW Debugger would be the EASIEST way to see where it crashes. You did say it crashes definitely, didn't you (as in BRK $00, etc)? The debugger is INVALUABLE in this aspect, you can see *EXACTLY* where it crashes as it runs.
Subj: Re: GS/OS Bugs 89-02-01 20:27:51 EST
From: BrianG19
As I already told Dave Lyons:
This is the ONLY code that is executed once GS/OS has passes control to my program before I am able to notice the 25 trashed bytes:
shortA (sep #$30 or whatever it is rep #$30.. i dunno)
stal $c010
:loop ldal $c000
bpl :loop
...
That's it! Either those lines are screwing up 25 bytes, or its GS/OS screwing them up before control is passed to my program.
-Brian
Subj: finding the bugs 89-02-01 23:29:09 EST
From: Dave Lyons
(ShortA is SEP $30, and it also tells the assembler to generate appropriate-length immediate-mode instructions.)
Other possibilities: The bytes were wrong to begin with, rather than getting trashed. (If the program works under ProDOS 16, is there something out of the ordinary about the OMF file that the GS/OS Loader deals with differently or incorrectly?)
The 25 possibly-trashed bytes appear to be valid code; WHAT WERE THEY SUPPOSED TO BE? Are you Listing them with the proper m/x register settings? Use Ctrl-N for 16-bit registers or Ctrl-R for 8-bit registers immediately before Listing in Nifty List to make sure you've got the right settings. (I say to do it immediately before because Listing through a SEP, REP, or XCE instruction affects Nifty List's settings.)
Subj: Re: GS/OS Bugs 89-02-02 13:17:38 EST
From: Dave HDS
From what I recall, GS/OS was originally not able to correctly load OML Version 1 files. A long shot, but worth checking, especially if the code is being genorated from Merlin 8/16...
If this is the case, just use the APW Compact (or ORCA/M equiv.) to update/convert the file to the lastest/most compact OML format and then try executing it...
Dave
Subj: Re: GS/OS Bugs 89-02-02 18:46:23 EST
From: AFL Scott
Hmm... I bet you mean OMF #1... Funny, I've had no problems, and I always have problems, very wierd ones (most are my fault, tho...)...
Subj: The Final Say 89-02-02 19:34:03 EST
From: BrianG19
Ok, folks, I screwed up. To make a long story short, those things that I thought were bugs in GS/OS are not bugs, but rather mistakes that _I_ made. I guess I jumped the gun. Sorry. As far as I know now, there are no fatal bugs in GS/OS.
Subj: GS/OS & OMF1? Locating bugs 89-02-02 20:18:26 EST
From: Dave Lyons
Hmmm...I haven't had any trouble with GS/OS and OMF v1 files--has anybody had problems? (With the GS/OS on System Disk 4.0, I mean--not the development versions!)
Brian, I'm glad you found the problem w/ your code. Brian described the problem in more detail by e-mail, and I'm going to summarize it because it may save other programmer's some frustration. It turned out that under ProDOS 16 the program's direct page was pre-filled with zeroes (or, at least, it typically had zeroes in it by accident), and a two-byte value's high byte was never being initialized.
This suggests a good defensive-programming technique: consider having your program fill its direct page with something Weird like $77s at the beginning--that way you'd be more likely to uncover problems with uninitialized values right away.
On the other hand, if you're worried that you're assuming some direct-page values are $00 when they have never been initialized, you might as well have your program fill the thing with $00s in the first place!
To get back to the topic at hand: GS/OS bugs probably exist, but finding them hard and time-consuming, and you should blame your own program _first_, partly because it's easier to look in your own program than in the system!
--Dave
Subj: Re: GS/OS Bugs 89-02-02 21:51:19 EST
From: AFL Scott
Dave,
I agree 100% as you WELL know!:)
Scott
Subj: OMF #1 89-02-03 10:38:14 EST
From: MikeW50
GS/OS loads OMF #1 just fine. There may well be some bugs with some features of the OMF, but if so, I have never encountered them.
Mike Westerfield
Subj: Dave's punctuation 89-02-03 19:52:34 EST
From: Dave Lyons
(Oops! Pardon my extra apostrophe 3 msgs back. :)
Subj: stack/direct-page segment, etc 89-02-04 14:22:48 EST
From: Dave Lyons
Ummm...Coach, how are you typing in your messages? The up-arrow key should be of great utility for making changes to previous paragraphs. :)
A couple notes on filling the stack/dir-pg segment. (1) Be careful _not_ to overwrite part of the stack that already has useful stuff on it! You can safely fill up to and including the byte that the S register points to. (2) When you look for the _pattern_ remaining to decide what the peak stack use was while your program ran, keep in mind that at least one toolset does (or used to) allocate a whole _page_ (256 bytes) of stack space, and I bet it doesn't use all of it! It could "hop over" your pattern and use some more memory below where you think it got. Just to confuse you.
Subj: Stack Overflows 89-02-06 15:38:07 EST
From: MikeW50
Also, if you happen to be using high-level languages, ORCA/Pascal has an option to check for stack overflows.
Mike Westerfield
Subj: discovering stack overflows 89-02-06 23:38:43 EST
From: Dave Lyons
Mike, I'm curious...how does the ORCA/Pascal stack overflow detection work? Given the problem I mentioned a few messages ago (if this is the right folder), I don't see a nice reliable way to do it.
Subj: Stack Overflows 89-02-07 16:55:14 EST
From: MikeW50
It isn't 100% reliable, Dave, at least not with tool calls. Basically, though, Pascal knows how much stack space it will need in a given subroutine (this information is available from the compile step), and it knows where the bottom of the stack is. The check subtracts the amount of space needed from the current stack location, and then looks to see if the result is above the min stack location. If not, it generates a run time error.
Mike Westerfield
Subj: Re: Compliments To ORCA/Pascal 89-02-07 21:54:39 EST
From: Coach101
A simple check (the stack check) that does not take a lot of time
and could save some real frustation in finding "random" disasters
in a "finsihed" program.
Dave, with respect to editing my message, I knew there were a
bunch of the "mentioned" typo and since I still put in my own
carriage returns (makes it easier to read when you download a
folder since I have not updated my "print" program to do "word
wrapping") making simple changes back up in the text can take
some time if you are a "neatnik". Ergo, I put the _EQU_ at the
